無線ネットワークにおけるブラインド・ノード問題を解消するための方法および装置

专利摘要:
ブラインド・ノード問題を解消するための技術が本明細書において説明されている。第１の態様は物理（ＰＨＹ）レイヤ上においてのみ動作し、第２の態様は、媒体アクセス制御（ＭＡＣ）レイヤ上で動作する。制御パケットおよびその他のパケットを検知するためにリソースを予約できるように、両方の態様が自身宛てではないデータ・パケットの処理を停止するノードを有する必要がある。この技術を実現するための装置も開示されている。
公开号:JP2011507398A
申请号:JP2010537997
申请日:2008-02-01
公开日:2011-03-03
发明作者:アブラハム、サントシュ；ナンダ、サンジブ；ナンダゴパラン、サイシャンカー；ワン、シャオフェイ
申请人:クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ；
IPC主号:H04W74-04

专利说明:

[0001] 開示される本態様は一般に無線ネットワーク・プロトコル、更に詳しくは無線ネットワークにおけるブラインド・ノード問題を解消するための方法および装置に関する。]
背景技術

[0002] 米国電気電子学会（ＩＥＥＥ）８０２．１１無線ローカル・エリア・ネットワーク（ＷＬＡＮ）規格が、近年かなりの人気を得ている。この規格群は、異なるトラフィックおよびユーザ・シナリオを扱うことを目的とした多様なシステム・デザインを用いて、広範囲の無線ネットワークをカバーしている。住宅用および商用の無線ネットワーク、メッシュ・ネットワーク、アド・ホック・ネットワーク、無線センサー・ネットワークなどといった、その他多数の無線ネットワーク・デザインが、ＩＥＥＥ８０２．１１規格に基づいている。]
[0003] ＩＥＥＥ８０２．１１に基づく無線ネットワークにおいて、送信要求（ＲＴＳ；ｒｅｑｕｅｓｔ ｔｏ ｓｅｎｄ）／送信準備完了（ＣＴＳ；ｃｌｅａｒ ｔｏ ｓｅｎｄ）のような制御メッセージが、無線媒体へのアクセスを予約するためにネットワークの多様なノードによって使用されている。ＲＴＳ／ＣＴＳメカニズムは、媒体を介して通信することを望むネットワークのノード間の干渉および衝突を最小化あるいは除去するために使用される。しかし、１つあるいは複数のノードがＲＴＳ／ＣＴＳ交換を検知できない際に、ＲＴＳ／ＣＴＳ交換を使用する媒体予約が失敗に終わるという１つのシナリオが発生する。なぜなら、ノードが誤ったＲＴＳ／ＣＴＳ交換を受信しようとしているからである。このシナリオは、ヒドゥン（ｈｉｄｄｅｎ）・ノード問題およびエクスポーズド（ｅｘｐｏｓｅｄ）・ノード問題のような広く認められた用語にあわせて、「ブラインド・ノード問題」と称される。この問題は、ＲＴＳ／ＣＴＳ制御パケットが媒体を予約するために使われている全ての通信システムにおいて生じうる。ブラインド・ノード問題は、局所的およびネットワーク全体の両方で、無線ネットワークのスループットおよび遅延パフォーマンス両方の低下の原因となる。]
[0004] よって、ＲＴＳ／ＣＴＳ無線媒体予約メカニズムに存在する無線ネットワークにおいて発生するブラインド・ノード問題を解消するための解決法に対する必要性が当該技術分野において存在する。]
[0005] 本明細書において開示される態様は、制御パケットおよびノードを宛先とされたその他のパケットを検知するためにリソースを予約することができるように、ノードを宛先とされていないデータ・パケットの処理を、このノード停止がすることによって、ブラインド・ノード問題に対処している。]
[0006] 態様において、少なくとも１つのヘッダ、および非ヘッダ情報を備えるパケットを受信することと、その非ヘッダ情報が処理されるべきかを判定するために少なくとも１つのヘッダを復号することとして、無線通信方法が実現される。]
[0007] 別の態様において、少なくとも１つのヘッダ、および非ヘッダ情報を備えるパケットを受信し、非ヘッダ情報が処理されるべきかを判定するために少なくとも１つのヘッダを復号するための、少なくとも１つのコンピュータによって実行可能なコードを含む機械読取可能媒体を有することとして、無線通信のためのコンピュータ・プログラム製品が実現される。]
[0008] さらに別の態様において、少なくとも１つのヘッダ、および非ヘッダ情報を備えるパケットを受信する手段と、非ヘッダ情報が処理されるべきかを判定するために少なくとも１つのヘッダを復号する手段を有することとして、無線通信装置が実現される。]
[0009] さらに別の態様において、少なくとも１つのヘッダ、および非ヘッダ情報を含むパケットを受信するように構成された受信機と、非ヘッダ情報が処理されるべきかを判定するために少なくとも１つのヘッダを復号するように構成された復号器とを有することとして、無線通信装置が実現される。]
[0010] さらに別の態様において、アンテナと、少なくとも１つのヘッダ、および非ヘッダ情報を備えるパケットをアンテナによって受信するのに適した受信機と、受信機に結合され、非ヘッダ情報が処理されるべきかを判定するために少なくとも１つのヘッダを復号するように構成された復号器とを有することとして、アクセス・ポイントが実現される。]
[0011] さらに別の態様において、少なくとも１つのヘッダ、および非ヘッダ情報を備えるパケットを受信するように適合された受信機を有することとして、アクセス端末が実現される。アクセス端末は、又、受信機に結合された復号器を含む。この復号器は、非ヘッダ情報が処理されるべきかを判定するために少なくとも１つのヘッダを復号するように構成されている。このアクセス端末は更に、非ヘッダ情報に基づいて表示を提供するように適合されたユーザ・インタフェースを含む。]
図面の簡単な説明

[0012] 図１は、ブラインド・ノード問題を説明するために使用されるネットワーク図である。
図２は、ブラインド・ノード問題を説明するために使用されるタイミング図である。
図３は、ブラインド・ノード問題に対処するための第１の態様のフロー図である。
図４は、ブラインド・ノード問題に対処するための第２の態様のフロー図である。
図５は、図３および図４の態様を説明するために使用されるタイミング図である。
図６は、図３および図４の態様を実現するように構成されたノードの構成要素のブロック図である。
図７、図３および図４の態様を実行するように構成されたノードの構成要素の第２のブロック図である。] 図１ 図２ 図３ 図４ 図５ 図６ 図７
実施例

[0013] 本開示の様々な態様が下記で説明されている。本明細書における教示は、多種多様な形態において実施されうるということと、本明細書で開示される任意の特定の構造、機能、あるいはその両方が単に代表例であるということが明らかであるべきである。本明細書における教示に基づいて、本明細書において開示される態様が、その他任意の態様とは独立して実現されうるということと、これらの態様の２つあるいは複数が様々な様式で組み合わせられうるということを、当業者は正しく理解するべきである。例えば、本明細書で述べられる多くの態様を使用して、装置が実現されるか、又は、方法が実行されうる。加えて、その他の構造、機能、あるいは、本明細書において述べられる態様の１つ又は複数に加えて、もしくはそれらを除いた、構造および機能を使用して、そのような装置が実現されうるか、あるいはそのような方法が実行されうる。更に、態様は請求項の少なくとも１つの要素を備えうる。]
[0014] 「典型的」という単語は本明細書において、「例、実例、例示として役立つこと」を意味するために使用される。「典型的」として本明細書において説明される実施形態は、必ずしもその他の態様より好ましいあるいは有利なものとして解釈されるものではない。更に、説明はＩＥＥＥ８０２．１１規格を必要とするネットワークを利用している。その他のプロトコルを活用するネットワークは、本明細書において開示される様々な技術およびシステムから利益を得うる。]
[0015] ここでは、図１において示されているように、単純な５ノード・ネットワーク１００を使用して、「ブラインド・ノード」問題と本明細書において称される通信問題が説明されている。ステーションＳＴＡ１ １０４およびアクセス・ポイントＡＰ１ １０２がお互いの範囲内にあり、「範囲内」にあるというのはこの２つのトランシーバ（例えば、ステーションＳＴＡ１ １０４およびアクセス・ポイントＡＰ１ １０２）が、お互いに通信できるということを意味する。同様に、図１において説明されるように、ステーションＳＴＡ３ １０８およびアクセス・ポイントＡＰ２ １１０は、お互いの範囲内にある。加えて、ステーションＳＴＡ２ １０６は、ＡＰ１ １０２およびステーションＳＴＡ３ １０８の両方の範囲内にある。しかし、ステーションＳＴＡ１ １０４およびＳＴＡ２ １０６はアクセス・ポイントＡＰ１ １０２と関連付けられており、またＳＴＡ３ １０８はアクセス・ポイントＡＰ２ １１０に関連付けられている。さらに、アクセス・ポイントＡＰ１ １０２およびＳＴＡ３ １０８はお互いの範囲内にはなく、またステーションＳＴＡ１ １０４およびステーションＳＴＡ２ １０６はお互いの範囲内にない。] 図１
[0016] ＩＥＥＥ８０２．１１プロトコルに従うノードの動作中に、ステーションＳＴＡ２ １０６によって、ステーションＳＴＡ１ １０４およびアクセス・ポイントＡＰ１ １０２の間の通信が著しく妨げられる場合に、ブラインド・ノード問題が生じる。ＳＴＡ３ １０８からアクセス・ポイントＡＰ２ １１０へ送り出されるデータ・パケットによってステーションＳＴＡ２ １０６がブラインドされている図１に再び関連して、ブラインド・ノード問題が説明されている。ステーションＳＴＡ２ １０６は、このデータ・パケットに注目し受信している一方でアクセス・ポイントＡＰ１ １０２によって送り出されるＣＴＳメッセージを見落としている。ステーションＳＴＡ２ １０６が情報をアクセス・ポイントＡＰ１ １０２に送信しようとしている場合、ステーションＳＴＡ２ １０６は、アクセス・ポイント１ １０２へのステーションＳＴＡ１ １０４によるデータ・パケットの送信を認識していない。そのため、ステーションＳＴＡ２ １０６は、アクセス・ポイントＡＰ１ １０２へ、ＲＴＳメッセージを送り出す。これは、アクセス・ポイントＡＰ１ １０２がＳＴＡ１ １０４から受信しているデータ・パケットと干渉し、そのデータ・パケットを破壊する恐れがある。] 図１
[0017] ステーションＳＴＡ３ １０８がアクセス・ポイントＡＰ２ １１０へ長いフレームを送信する処理に従事している図２において示されるようなタイミング図２００に加えて、詳細な説明が以下に述べられる。ステーションＳＴＡ３ １０８は、データ・パケット２１４を送信し始める前に、ＲＴＳメッセージ２１２を送信し、ＣＴＳメッセージ２０２をＡＰ２ １１０から受信するだろう。ステーションＳＴＡ２ １０６はＳＴＡ３ １０８の範囲内にあるので、プロトコルの動作から命令されたように、ステーション３ １０８からのプリアンブルを検知し、ステーション３ １０８からのパケットのビットを蓄積し続けるだろう。データ・パケット２１４が復号され、その中に含まれる宛先アドレスがステーションＳＴＡ２ １０６と一致しなかった場合、データ・パケット２１４はステーションＳＴＡ２ １０６によって破棄されるだろう。しかし、その間、ステーションＳＴＡ２ １０６は、ＲＴＳメッセージ２１２に基づいて、ＮＡＶ２５２を設定しうる。ステーションＳＴＡ１ １０４がアクセス・ポイントＡＰ１ １０２へＲＴＳメッセージ２２２を送る場合、アクセス・ポイントＡＰ１ １０２は、ステーションＳＴＡ３ １０８とアクセス・ポイントＡＰ２ １１０との間の通信によって影響されないので、ＣＴＳメッセージ２３２で応答する。その後、ステーションＳＴＡ１ １０４はアクセス・ポイントＡＰ１ １０２へデータ・パケット２２４を送り始めうる。ＳＴＡ２ １０６はステーションＳＴＡ３ １０８からのデータ・パケット２１４に注目しているので、アクセス・ポイントＡＰ１ １０２からのＣＴＳメッセージ２３２はＳＴＡ２ １０６によって検知されない。ＡＣＫメッセージ２１６によって示されるように、ステーションＳＴＡ３ １０８とアクセス・ポイントＡＰ２ １１０の間でのデータ転送が完了すると、ステーションＳＴＡ２ １０６は、アイドル状態になり周りの媒体を感知するだろう。なぜなら、ステーションＳＴＡ２ １０６はステーションＳＴＡ１ １０４の送信範囲内にあるのではなく、ステーションＳＴＡ１ １０４とアクセス・ポイントＡＰ１ １０２の間でのＲＴＳ／ＣＴＳメッセージの交換を検知しないためである。ステーションＳＴＡ２ １０６は、その後アクセス・ポイントＡＰ１ １０２へＲＴＳメッセージ２４２（あるいはデータ）を送りはじめうる。それが進行中のステーションＳＴＡ１ １０４とアクセス・ポイントＡＰ１ １０２の間でのデータ・パケット２２４の送信と衝突する。] 図２
[0018] アグリゲーションが使用される場合、ステーションＳＴＡ１ １０４とアクセス・ポイントＡＰ１ １０２との間のデータ・フレームが大きく、ステーションＳＴＡ２ １０６からのいくつかの送信がフレーム持続期間内に試みられうるということに留意されたい。これらの衝突は、アクセス・ポイントＡＰ１ １０２での、ステーションＳＴＡ１ １０４からのフレームの復号における誤りの原因となりうる。]
[0019] ステーションＳＴＡ２ １０６がアクセス・ポイントＡＰ１ １０２への送信を試みたのは、ステーションＳＴＡ２ １０６が、アクセス・ポイントＡＰ１ １０２からのＣＴＳメッセージ２３２を見落とし、またステーションＳＴＡ１ １０４の範囲外にあるからである、ということに留意されたい。その結果として、ステーションＳＴＡ２ １０６は自身宛てのものではないパケットを復号していた。ＲＴＳおよびＣＴＳのような予約パケットは低ＳＮＲで復号されうるレートで送られ、ステーションＳＴＡ２ １０６がステーションＳＴＡ３ １０８からのデータ・パケット２１４を復号しようとすることによって、媒体内のその他のパケットに対して「ブラインド」されるため、この問題はブラインド・ノード問題と呼ばれている、ということにも留意されたい。]
[0020] 上述された例における２つのアクセス・ポイントおよび３つのステーションの例示は任意のものである。同じ問題がその他多数のシナリオにおいて生じるだろう。例えば、ネットワークにおける５つ全てのノードは、インディペンデント・ベーシック・サービス・セット（ＩＢＳＳ）におけるＳＴＡか、無線センサー・ネットワークにおける同等のセンサー・ノードか、拡張サービス・セット・メッシュ・ネットワーク（ＥＳＳ Ｍｅｓｈ）におけるメッシュ・ポイント（ＭＰ）、ＳＴＡ、およびメッシュ・アクセス・ポイント（ＭＡＰ）でありうる。]
[0021] ブラインド・ノード問題を解消するために、他のノード宛てのパケットによってブラインドされるノードは、そのようなパケットを復号することを停止することができるべきであり、媒体内にある予約パケットを受信し復号できるべきである。この問題の解消を試みるために、２つの態様が採用されうる。第１の態様は物理（ＰＨＹ）レイヤにおける実現を伴い、第２の態様は媒体アクセス制御（ＭＡＣ）レイヤを伴う。]
[0022] 図３はブラインド・ノード問題に対処するために、ノードのＰＨＹレイヤにおいて実現される第１の処理３００を例示している。処理３００は、ノードが初期化された後にアイドル状態に入るステップ３０２から始まる。アイドル状態の間、ノードは別のノードの送信を検知しようとする。更に、アイドル状態の間、ノードは先行して受信されたパケットに従いＮＡＶ期間を既に設定することができる。第１の処理３００の動作は、図１において例示されているネットワーク構成および図５を参照して説明される。この説明において称されるように、「ノード」とはステーションＳＴＡ２ １０６であるが、ブラインド・ノード問題に対処するため第１の処理３００に従って動作している場合のステーションＳＴＡ２ １０６を除く。] 図１ 図３ 図５
[0023] ステップ３０４において、ノードはパケットの送信に属する信号を検知し、ステップ３０６へと進む。ここでは、ノードがプリアンブルおよびＰＬＣＰヘッダを復号する。その後、ステップ３０８において、ＮＡＶ期間内にパケットが検知されたかが判定される。図５における時間Ｔ０の前のように、ノードがＮＡＶ期間内ではない場合、動作はステップ３１４で継続する。ここでは、パケットが通常に処理され（例えば、パケットが送信者および受信者を判定するために復号され、例えば、そのパケットがそのノード宛てである場合には応答し）、ノードはステップ３０２のアイドル状態に戻る。図５における時間Ｔ１のＮＡＶ期間５５２のように、ノードが現在ＮＡＶ期間内にある場合、動作はステップ３１０で継続する。] 図５
[0024] ノードが現在ＮＡＶ期間内にあるステップ３１０では、ノードは一切要求を送信しない。既存のＮＡＶ期間５５２によるＮＡＶ期間内にノードが存在する時間を延長するようＮＡＶ期間５５４が設定されている場合、ノードは、図５における時間Ｔ２におけるように、ＮＡＶ期間を延長するであろうＲＴＳ／ＣＴＳパケットのようなメッセージにのみに関心がある。このように、ステップ３１０において、例えば、データ・パケット５１４を送信するためのステーションＳＴＡ３ １０８とアクセス・ポイントＡＰ２ １１０との間での交換に関連するＲＴＳメッセージ５１２あるいはＣＴＳメッセージ５０２、あるいは、データ・パケット５２４を送信するためのステーションＳＴＡ１ １０４とアクセス・ポイントＡＰ１ １０２の間での交換に関連するＲＴＳメッセージ５２２あるいはＣＴＳメッセージ５３２のようなＲＴＳ／ＣＴＳパケットをパケットが含んでいるかを、ノードが判定する。態様において、ＲＴＳ／ＣＴＳパケットは一定の持続時間を有しているので、ノードはＰＬＣＰヘッダに含まれているパケットの持続時間を調べることによって、パケットがＲＴＳ／ＣＴＳパケットを含んでいるかを判定する。ＲＴＳ／ＣＴＳパケットによって費やされる時間は一定であるので、ＰＨＹレイヤ処理エンティティへと「ハード・コード化」されうるということに留意されたい。フレームがＲＴＳ／ＣＴＳパケットであると持続期間フィールドが示した場合、ノードはパケットを復号するために必要とされる全ての動作を実行する。別の態様において、ノードはタイプ情報を含むＭＡＣヘッダを調べることによって、パケットがＲＴＳ／ＣＴＳパケットを含んでいるかを判定する。メッセージがＲＴＳ／ＣＴＳパケットではない場合、動作はステップ３１６で継続する。そうではなくメッセージがＲＴＳ／ＣＴＳパケットである場合は、動作はステップ３１２で継続する。更に、ＡＣＫメッセージ５１６のようなＡＣＫメッセージは、ノードによって無視されるか、ＮＡＶ期間５１６のような、以前に設定されたＮＡＶ期間が終了しているかを確認しうる。] 図５
[0025] メッセージがＲＴＳ／ＣＴＳパケットではないとノードによって判定されるステップ３１６において、ノードはパケットを無視する。具体的にいうと、ノードがプリアンブルおよびＰＬＣＰヘッダを復号し、図５における時間Ｔ１におけるように、パケットがＲＴＳパケットでもＣＴＳパケットでもなく、データ・パケット５１４のようなデータ・パケットだと持続期間フィールドが示した場合、ノードは、これが前のＲＴＳあるいはＣＴＳ（例えば、ＲＴＳメッセージ５１２あるいはＣＴＳメッセージ５０２）のためのデータ・パケットに対応しており、自分にアドレスされていないと判定する。ノードはその後、パケットを復号するための一切の更なるビットを蓄積するのを止め、その他任意の新しいパケットのプリアンブルを感知するためのモードへと戻る。その後、動作はステップ３０２に戻り、ノードは他のプリアンブルを傍受するために再びアイドル状態に入る。ノードは低ＳＩＮＲのためにＲＴＳパケットあるいはＣＴＳパケットのいずれをも受信しないかもしれないが、これがどちらかを受信する限り、それに応じて動作するということに留意されたい。] 図５
[0026] パケットが予めＲＴＳ／ＣＴＳパケットだと判定されているステップ３１２において、ノードはパケットの宛先を判定する。パケットがそのノード宛てである場合、動作はステップ３１４で継続し、パケットが通常のように処理される。しかし、パケットの宛先がそのノードでない場合、動作はステップ３１８で継続する。]
[0027] ステップ３１８において、図５における時間Ｔ１あるいは時間Ｔ２でのように、ノードが、そのノード以外のノード宛てとされているデータのＲＴＳ／ＣＴＳパケット（例えば、ＲＴＳメッセージ５１２／５２２あるいはＣＴＳメッセージ５０２／５３２）を復号したと判定した場合、ノードは期間を設定するか、あるいはＮＡＶ期間５５４に基づく追加の量まで、ＮＡＶ期間５５２を延長するように、ＮＡＶ期間を延長する。一般に、ＲＴＳ／ＣＴＳパケットの受信時間に基づいて、ノードはデータ・フレームが到着する時間Ｔｎ、およびデータのためのパケット送信がどのくらい続くかを判定しうる。] 図５
[0028] 一般に、ＮＡＶによって示された持続期間の間、ノードは標準的なプロトコルに従う手法で進行する。すなわち、ノードはパケットがＲＴＳ／ＣＴＳ持続期間のパケットかを判定するために、各プリアンブルおよびＰＬＣＰレイヤをチェックする。ＲＴＳ／ＣＴＳパケットとは異なる持続期間を有するパケットはそれ以上処理されず、ノードは他のプリアンブルを検知することに移行する。ＲＴＳ／ＣＴＳパケットであるパケットに対して、これらのパケットがノードによって正しく復号された場合、ノードのＮＡＶが新しいＲＴＳ／ＣＴＳに従って延長されうる。]
[0029] 図５において示されるように、ステーションＳＴＡ１ １０４からアクセス・ポイントＡＰ１ １０２へ送信されるデータ・パケット５２４はステーションＳＴＡ２ １０６からの送信によって妨害されない。ステーションＳＴＡ２ １０６は、送信を試みる前に、アクセス・ポイントＡＰ１ １０２から送られる（ステーションＳＴＡ１ １０４からのデータ・パケット５１４の受取を確認するためにステーションＳＴＡ３によって送られるＡＣＫメッセージ５１６のような）ＡＣＫメッセージを待つ。] 図５
[0030] 図４は、ブラインド・ノード問題に対処するための第２の処理４００を例示している。第２の処理４００は、ノードのＭＡＣレイヤにおいて実現され、ノードが初期化された後にアイドル状態に入るステップ４０２で始まるアイドル状態の間、ノードは別のノードの送信を検知しようとする。第２の処理４００の動作は、図５を参照して説明される。] 図４ 図５
[0031] ステップ４０４において、ノードはパケットの送信に属する信号を検知して、ステップ４０６へ進む。ここでは、ノードがプリアンブル、ＰＬＣＰヘッダ、それからＭＡＣヘッダを復号する。]
[0032] 具体的に言うと、ステップ４０６において、ノードが任意のパケットのプリアンブルおよびＰＬＣＰを受信した場合、ノードはＭＡＣヘッダに対応する十分なビットを蓄積し復号することに取り掛かる。ＭＡＣヘッダのための処理を実行する一方で、ノードはパケットのその後のビット／シンボルを蓄積し続ける。しかし、ノードは、パケットが完全に蓄積されることを待つことなく、ヘッダ・ビットの復号を続行する。ステップ４０８において、示された宛先アドレスがそのノードと一致するか、あるいはパケットがＲＴＳ／ＣＴＳパケットのようなブロードキャスト・パケットもしくは制御パケットか、を判定するためにＭＡＣヘッダは使用される。]
[0033] ステップ４１２では、そのノードが本当にフレームの宛先である場合、あるいはパケットがブロードキャスト、もしくはＲＴＳ／ＣＴＳかその他の制御パケットである場合、フレームが完全に蓄積され復号される。]
[0034] そのノードが宛先でない場合、ノードでのパケットの復号機能および蓄積機能はステップ４１０において終了し、ノードはその他任意の新しいパケットのプリアンブルを感知するためのモードへと戻る。]
[0035] 上記の手順のいずれか１つ、あるいは両方が、８０２．１１デバイスにおいて実現されうる。パケットの復号機能がＲＴＳ／ＣＴＳパケットではないと判定されるパケットに対しては実施されないという利点を、図３におけるＰＨＹレイヤのみの態様は有している。よって、ノードは電力リソースを節約しうる。しかし、このＰＨＹレイヤのみの態様は、媒体予約のためのＲＴＳ／ＣＴＳによる方法がたまにしか使用されないネットワークにおいては役に立たない。加えて、ＰＨＹレイヤのみの態様では、判定が持続期間フィールドにのみに基づいてなされるので、そのノード宛てのパケットが見落とされる原因となりうる。図４のＭＡＣレイヤの態様は、あらゆるシナリオにおいて役に立ち、パケット・デコーダに対して、パケットの処理を実行することを要求する。] 図３ 図４
[0036] 図６は、図３のＰＨＹレイヤのみの態様、および図４のＭＡＣレイヤのみの態様を実行するために構成されたノードの受信機部６００の構成を例示している。この図に示されるように、受信機部６００は、ノードによって受信される様々なパケットを運ぶ無線信号を受信するために使用されるアンテナ・モジュール６０２を含む。アンテナ・モジュール６０２は、無線信号を送信されるためにも同様に使用されうる。アンテナ・モジュール６０２には、受信機モジュール６０４が結合されている。受信機モジュール６０４は、無線信号を介して送信され、アンテナ・モジュール６０２によって受信されたパケットを受信するように構成されている。復号器モジュール６０６は、受信機モジュール６０４に結合されている。復号器モジュール６０６は、受信機モジュール６０４によって受信されたパケットのヘッダおよびその他の部分を復号するように構成されている。] 図３ 図４ 図６
[0037] 図７は、図３のＰＨＹレイヤのみの態様および図４のＭＡＣレイヤのみの態様を実現するように構成されたノードの受信機部７００の第２の構成を例示している。受信機部７００は、少なくとも１つのヘッダ、および非ヘッダ情報を含むパケットを受信するモジュール７０２、および非ヘッダ情報が処理されるべきかを判定するための少なくとも１つのヘッダを復号するモジュール７０４を含む。] 図３ 図４ 図７
[0038] 当業者は、情報および信号が多様な異なるテクノロジーとテクニックのいずれかを使用して表現されうるということを理解するだろう。例えば、上記の説明を通して参照されうるデータ、命令群、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁場あるいは磁気粒子、光学場あるいは光学粒子、あるいはそれらのいずれかの組み合わせによって表現されうる。]
[0039] 当業者はさらに本明細書で開示された態様に関連付けて説明された多様な実例的な論理ブロック、モジュール、回路、およびアルゴリズム・ステップは、電子ハードウェア、コンピュータ・ソフトウェア、あるいはこれら両方の組み合わせによって実現されうるということを正しく理解するだろう。このハードウェアおよびソフトウェアの互換性を明確に例示するために、多様な実例的な構成要素、ブロック、モジュール、回路、およびステップが、一般にそれらの機能の観点から上記で説明されている。そのような機能がハードウェアとして、あるいはソフトウェアとして実現されるかどうかは、システム全体に課せられている特定のアプリケーションおよび設計の制約に依存する。当業者は、各特定のアプリケーションのために方式を変化させることによって、述べられた機能性を実施しうるがこういった実施判定は本発明の範囲からの逸脱をまねくものと解釈されるべきではない。]
[0040] 本明細書において開示された態様に関連付けて説明されたアルゴリズムあるいは方法のステップは、直接的にハードウェアにおいて、プロセッサによって実行されるソフトウェア・モジュールにおいて、あるいはこの２つの組み合わせにおいて実施されうる。ソフトウェア・モジュールは、ＲＡＭメモリ、フラッシュ・メモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハード・ディスク、リムーバブル・ディスク、ＣＤ−ＲＯＭ、あるいは当該技術分野において周知のその他任意の形態の記憶媒体に存在しうる。典型的な記憶媒体は、記憶媒体からの情報を読み取り、記憶媒体に情報を書き込むことができるプロセッサのようなプロセッサと結合される。別の方法としては、記憶媒体はプロセッサに不可欠でありうる。プロセッサおよび記憶媒体はＡＳＩＣ内に存在しうる。ＡＳＩＣはユーザ端末内に存在しうる。別の選択肢として、プロセッサおよび記憶媒体は離散的な構成要素としてユーザ端末内に存在しうる。さらに、いくつかの態様において任意の適切なコンピュータ・プログラム製品は、本開示の態様の１つあるいは複数に関連する（例えば、少なくとも１つのコンピュータによって実行可能な）コードを備える機械読取可能媒体を備えうる。いくつかの態様において、コンピュータ・プログラム製品はパッケージ・マテリアルを備えうる。]
[0041] 本明細書における教示は、様々な装置（例えば、デバイス）に組み込まれうる（例えば、それらにおいて実現される、あるいはそれらによって実行される）。例えば、各ノードはアクセス・ポイント（「ＡＰ」）、ノードＢ、ラジオ・ネットワーク・コントローラ（「ＲＮＣ」）、ｅノードＢ、基地局コントローラ（「ＢＳＣ」）、ベース・トランシーバ局（「ＢＴＳ」）、基地局（「ＢＳ」）、トランシーバ機能（「ＴＦ」）、ラジオ・ルータ、ラジオ・トランシーバ、基本サービス・セット（「ＢＳＳ」）、拡張サービス・セット（「ＥＳＳ」）、ラジオ基地局（「ＲＢＳ」）、あるいはその他のテクノロジーとして構成されるか、あるいは当該技術において称される。あるノードは、加入者局とも称されうる。加入者局は、加入者ユニット、モバイル局、遠隔局、遠隔端末、アクセス端末、ユーザ端末、ユーザ代行者、ユーザ・デバイス、あるいはユーザ機器としても知られる。いくつかの実施において、加入者局はセルラ電話、コードレス電話、セッション初期化プロトコル（「ＳＩＰ」）電話、無線ローカル・ループ（「ＷＬＬ」）局、情報携帯端末（「ＰＤＡ」）、無線接続機能を有するハンドヘルド・デバイス、あるいはその他いくつかの適切な無線モデムに接続された処理デバイスを備えうる。よって、本明細書で教示される１つあるいは複数の態様は、電話（例えば、セルラ電話あるいはスマートフォン）、コンピュータ（例えば、ラップトップ）、ポータブル通信デバイス、ポータブル・コンピューティング・デバイス（例えば、個人用データ・アシスタント）、エンタテイメント・デバイス（例えば、音楽デバイスかビデオ・デバイス、あるいは衛星ラジオ）、全地球位置測定システム・デバイス、あるいは無線媒体によって通信するように構成されたその他任意の適切なデバイスに組み込まれうる。]
[0042] 無線デバイスは、任意の適切な無線通信テクノロジーに基づいて、１つあるいは複数の無線通信リンクによってよって通信しうるか、あるいはこれらをサポートすることができる。例えば、いくつかの態様において、無線デバイスはネットワークと関連付けられうる。いくつかの態様において、ネットワークはボディ・エリア・ネットワークあるいはパーソナル・エリア・ネットワーク（例えば、超広帯域ネットワーク）を備えうる。いくつかの態様において、ネットワークはローカル・エリア・ネットワークあるいはワイド・エリア・ネットワークを備えうる。無線デバイスは、様々な無線通信テクノロジー、プロトコル、あるいは、例えばＣＤＭＡ、ＴＤＭＡ、ＯＦＤＭ、ＯＦＤＭＡ、ＷｉＭＡＸ、およびＷｉＦｉのような規格、のうちの１つあるいは複数をサポートしているか、あるいは使用することができる。同様に、無線デバイスは様々な対応する変調スキームあるいは多重化スキームのうち１つあるいは複数をサポートしているか、あるいは使用することができる。このように、無線デバイスは、上記のあるいはその他の無線通信テクノロジーを使用する１つあるいは複数の無線通信リンクによって確立あるいは通信するための適切な構成要素（例えば、エア・インタフェース）を含みうる。例えば、デバイスは無線媒体を介して通信を容易にする様々な構成要素（例えば、信号発生器および信号プロセッサ）を含みうる送信機構成要素および受信機構成要素に関連付けられた無線トランシーバを備えうる。]
[0043] 本明細書において開示される態様に関連付けて説明される多様な例示的な論理ブロック、モジュール、および回路は、集積回路（「ＩＣ」）、アクセス端末、あるいはアクセス・ポイントによって実行、あるいはそれらにおいて実現される。ＩＣは汎用プロセッサ、ディジタル信号プロセッサ（ＤＳＰ）、アプリケーション特定集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）あるいは他のプログラマブル・ロジック・デバイス、離散ゲートもしくはトランジスタ・ロジック、離散ハードウェア構成要素、電子構成要素、光学構成要素、機械構成要素、あるいは本明細書で説明された機能を実行するために設計されたそれらの任意の組み合わせを備えうるし、ＩＣ内、ＩＣ外、あるいはその両方に存在するコードあるいは命令群を実行しうる。汎用プロセッサはマイクロプロセッサでありうるが、別の方法としては、プロセッサは従来型の任意のプロセッサ、コントローラ、マイクロコントローラ、あるいはステート・マシンでありうる。プロセッサは例えば、ＤＳＰおよびマイクロプロセッサの組み合わせ、複数のマイクロ・プロセッサ、ＤＳＰコアと連携した１つあるいは複数のマイクロプロセッサ、あるいはその他の任意の構成のようなコンピューティング・デバイスとしても実施されうる。]
[0044] 開示された態様の上記記述は、当業者に対して本開示を製造あるいは使用することを可能にするために提供される。 これらの態様に対する多様な変形例は当業者にとって容易に明らかになるであろう。また本明細書で規定された一般的原理は、この開示の精神あるいは範囲から逸脱することなく他の態様に適用されうる。よって、本開示は本明細書で示される態様に限定されるよう意図されたものではなく、本明細書で開示された原理および新規の特徴と矛盾しない最大範囲であると認められるべきである。]

权利要求:

請求項1
無線通信方法であって、少なくとも１つのヘッダ、および非ヘッダ情報を備えるパケットを受信することと、前記非ヘッダ情報が処理されるべきかを判定するために前記少なくとも１つのヘッダを復号することとを備える方法。
請求項2
前記パケットを受信することが、受信ノードにおいてなされ、前記少なくとも１つのヘッダを復号することは、パケットの宛先を判定することと、前記宛先が前記受信ノードとは異なるノードであると判定されると、別のパケットの送信をモニタすることに戻ることとを備える請求項第１に記載の方法。
請求項3
前記宛先が前記受信ノードとは異なるノードであると判定されると、第１のタイミング・パラメータを設定することを更に備える請求項２に記載の方法。
請求項4
前記第１のタイミング・パラメータが、前記受信ノードが送信要求（ＲＴＳ）の送信を回避するネットワーク割当ベクトル（ＮＡＶ）である請求項３に記載の方法。
請求項5
前記宛先が前記受信ノードとは異なるノードであると判定されると、前記非ヘッダ情報の更なる処理を停止することを更に備える請求項２に記載の方法。
請求項6
前記少なくとも１つのヘッダを復号することが、前記パケットのタイプを判定することと、前記タイプが制御パケットだと判定されると、前記非ヘッダ情報を処理することとを備える請求項１に記載の方法。
請求項7
前記制御パケットが、送信要求（ＲＴＳ）パケットおよび送信準備完了（ＣＴＳ）パケットのうちの１つである請求項６に記載の方法。
請求項8
無線通信のコンピュータ・プログラム製品であって、少なくとも１つのヘッダ、および非ヘッダ情報を備えるパケットを受信し、前記非ヘッダ情報が処理されるべきかを判定するために前記少なくとも１つのヘッダを復号するように、少なくとも１つのコンピュータによって実行可能なコードを備えるコンピュータ読取可能媒体を備えるコンピュータ・プログラム製品。
請求項9
無線通信装置であって、少なくとも１つのヘッダ、および非ヘッダ情報を備えるパケットを受信する手段と、前記非ヘッダ情報が処理されるべきかを判定するために前記少なくとも１つのヘッダを復号する手段とを備える装置。
請求項10
前記パケットを受信することが、受信ノードにおいてなされ、前記少なくとも１つのヘッダを復号する手段は、前記パケットの宛先を判定する手段と、前記宛先が前記受信ノードとは異なるノードであると判定されると、別のパケットの送信をモニタすることに戻る手段とを備える無線通信装置。
請求項11
前記宛先が前記受信ノードとは異なるノードであると判定されると、第１のタイミング・パラメータを設定する手段を更に備える請求項１０に記載の無線通信装置。
請求項12
前記第１のタイミング・パラメータが、前記受信ノードが送信要求（ＲＴＳ）の送信を回避するネットワーク割当ベクトル（ＮＡＶ）である請求項１１に記載の無線通信装置。
請求項13
前記宛先が前記受信ノードとは異なるノードであると判定されると、前記非ヘッダ情報の更なる処理を停止する手段を更に備える請求項１０に記載の無線通信装置。
請求項14
前記少なくとも１つのヘッダを復号する手段が、前記パケットのタイプを判定する手段と、前記タイプが制御パケットだと判定されると、前記非ヘッダ情報を処理する手段とを備える請求項９に記載の無線通信装置。
請求項15
前記制御パケットが、送信要求（ＲＴＳ）パケットおよび送信準備完了（ＣＴＳ）パケットのうちの１つである請求項１４に記載の無線通信装置。
請求項16
無線通信装置であって、少なくとも１つのヘッダ、および非ヘッダ情報を備えるパケットを受信するように構成された受信機と、前記非ヘッダ情報が処理されるべきかを判定するために前記少なくとも１つのヘッダを復号するように構成された復号器とを備える装置。
請求項17
前記受信機は受信ノードであり、前記復号器が、パケットの宛先を判定し、前記宛先が前記受信ノードの宛先とは異なるノードであると判定されると、別のパケットの送信をモニタすることに戻るよう更に構成された請求項１６に記載の装置。
請求項18
前記宛先が前記受信ノードとは異なるノードであると判定されると、復号器が第１のタイミング・パラメータを設定するよう更に構成された請求項１７に記載の装置。
請求項19
前記第１のタイミング・パラメータが、前記受信ノードが送信要求（ＲＴＳ）の送信を回避するネットワーク割当ベクトル（ＮＡＶ）である請求項１８に記載の装置。
請求項20
前記宛先が前記受信ノードとは異なるノードであると判定されると、前記復号器が前記非ヘッダ情報の更なる処理を停止するよう更に構成された請求項１７に記載の装置。
請求項21
前記復号器が、前記パケットのタイプを判定し、前記タイプが制御パケットだと判定されると、前記非ヘッダ情報を処理するよう更に構成された請求項１６に記載の装置。
請求項22
前記制御パケットが、送信要求（ＲＴＳ）パケットおよび送信準備完了（ＣＴＳ）パケットのうちの１つである請求項２１に記載の装置。
請求項23
アクセス・ポイントであって、アンテナと、少なくとも１つのヘッダ、および非ヘッダ情報を備えるパケットを、前記アンテナによって、受信するように適合された受信機と、前記受信機に結合され、前記非ヘッダ情報が処理されるべきかを判定するために、前記少なくとも１つのヘッダを復号するように構成された復号器とを備えるアクセス・ポイント。
請求項24
アクセス端末であって、少なくとも１つのヘッダ、および非ヘッダ情報を備えるパケットを受信するように適合された受信機と、前記受信機に結合され、前記非ヘッダ情報が処理されるべきかを判定するために前記少なくとも１つのヘッダを復号するように構成された復号器と、前記非ヘッダ情報に基づいて、表示を提供するように適合されたユーザ・インタフェースとを備えるアクセス端末。